Method and apparatus for a comprehensive network management system

ABSTRACT

In a system for managing data, voice, application and video networks and associated systems and services that comprise multiple, interconnected network technologies, a management system suited for a particular networking technology manages each separate technology domain. Multiple management systems thus manage multiple domains with respect to fault, configuration, accounting, performance, and security management. The management systems that manage the individual networking technology domains are then themselves managed by a higher-level system, called an inter-domain management system, which performs cross-domain management. The individual management systems of the invention collect data from their respective technology domains and provide it to an intra-domain data collection function. This data is then utilized by an inter-domain data correlation function to determine what instructions should be sent from an intra-domain instruction function to each management system for implementation in its respective technology domains. The comprehensive management system thus collects data from each lower-level management system and, if required, sends operational instructions back to each lower level system. Event correlation and service level management are performed at both the intra-domain and inter-domain levels. Business process management is performed at the inter-domain level.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 60/217,968, filed Jul. 13, 2000.

FIELD OF THE INVENTION

The invention relates to management of communications networks and, inparticular, to comprehensive management of a network comprised ofmultiple interconnected networking technologies and associated systems,including management of multi-domain services.

BACKGROUND

Traditionally, networks and services that consist of, or depend upon,several different interconnected networking technologies and associatedsystems and applications, often referred to as multi-domain orheterogeneous networks, have been managed piece-meal, typicallyutilizing several management systems dedicated to the specificnetworking technologies and applications. This makes it very difficultto manage the multi-domain network from an end-to-end perspective.Because this method is non-comprehensive and largely non-automated, ittends to be expensive and error-prone, requiring the coordination anduse of many different individuals and resources, as well as disparatemanagement systems.

Today's business and service networks are complex. Since the currentstate of any particular network has more than likely evolved in apiecemeal fashion, it likely includes heterogeneous kinds of networktechnologies, equipment from multiple vendors, and various kinds ofmanagement methods. To make matters worse, management methods varybetween countries and even between districts within countries. In manycases, the result is either piecemeal management, in which narrowlyfocused management solutions co-exist but do not cooperate, or nomanagement at all.

FCAPS (fault, configuration, accounting, performance, and security)management is possible for most individual networking technologies andassociated systems and applications. However, these functions aretypically provided by management systems that manage only that specifickind of networking technology, system, or application. AprismaManagement Technologies' Spectrum® Management System is an example of anexisting management system that has this capability. The best case,however, would be integrated management, in which these managementtechniques cooperate in a standardized management framework.

What has been needed, therefore, is a consolidated, automated managementtool that can manage networks and services that extend across multipleinterconnected underlying networking technologies and associated systemsand applications, thus providing management for multi-domain services.

OBJECTS OF THE INVENTION

The object of the present invention is to provide a means by which tomanage a multi-domain network consisting of multiple interconnectednetworking technologies and associated systems and applications,including the ability to perform fault, configuration, accounting,performance, and security (FCAPS) management. A further object of thepresent invention is to provide end-to-end management of multi-domainservices, including element, network, service, and business processmanagement.

SUMMARY

The comprehensive network management system of the invention (i)integrates the management of networks, systems, business applications,and services (ii) integrates the areas of fault, configuration,accounting, performance, and security management, (iii) integrates theelement, network, service, and business layers of managementinformation, (iv) integrates the management of diverse networkingtechnologies, and (v) integrates the management methods of bothtelecommunications and data communications networks.

The invention is a comprehensive system for managing data, voice,application and video networks and associated systems and services thatcomprise multiple, interconnected network technologies. In one aspect ofthe invention, a management system suited for a particular networkingtechnology manages each separate technology domain. Multiple managementsystems thus manage multiple domains with respect to fault,configuration, accounting, performance, and security (FCAPS) management.The management systems that manage the individual networking technologydomains are then themselves managed by a higher-level system, called aninter-domain management system, which performs the task of cross-domainmanagement.

The individual management systems of the invention collect data fromtheir respective technology domains and provide it to an intra-domaindata collection function. This data is then utilized by an inter-domaindata correlation function to determine what instructions should be sentfrom an intra-domain instruction function to each management system forimplementation in its respective technology domain. The comprehensivemanagement system thus collects data from each lower-level managementsystem and, if required, sends operational instructions back to eachlower level system.

In the present invention, management functions are performed from asingle console and over multiple interconnected underlying networkingtechnologies. The enabling technology for cross-domain management is thesame technology that permits operation, administration and maintenanceof the underlying networking technologies. Event correlation and servicelevel management are performed at both the intra-domain and inter-domainlevels, and business process management is performed at the inter-domainlevel.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of an embodiment of a comprehensivenetwork management system according to the present invention;

FIG. 2 is a table illustrating the different dimensions of integratednetwork management;

FIG. 3 is a block diagram illustrating the generic components of anetwork;

FIG. 4 illustrates two different conceptual models for the integrationof element and network management;

FIG. 5 is a block diagram illustrating the conceptual architecture of anenterprise management system that may be employed for cross-domainmanagement in an embodiment of the invention;

FIG. 6 is an example of a network comprised of multiple interconnectednetworking technologies that may be managed by use of the presentinvention;

FIG. 7 is utilized to discuss the management challenge provided by themanagement of domains controlled by different entities;

FIG. 8 is a conceptual model of intra-domain event correlation asutilized by the present invention;

FIG. 9 is the Telecommunications Model Network (TMN) conceptual model ofintegrated management;

FIG. 10 is a conceptual depiction of how service level management isutilized in conjunction with enterprise management in one embodiment ofthe invention; and

FIG. 11 illustrates the operation of an embodiment of the comprehensivenetwork management system of the present invention.

DETAILED DESCRIPTION

The present invention is a comprehensive network management system formanaging data, voice, application and video networks that (i) integratesthe management of diverse, but connected network technologies, (ii)includes the management of systems and software applications at customerpremises, and (iii) allows for the provisioning, billing, and control ofservices that span across multiple kinds of networks. The inventionallows comprehensive network management from a single console and overmultiple interconnected underlying networking technologies andmulti-domain services. It is an automated, consolidated management tool.It has tight integration with underlying element and network managementsystems.

In the present invention, a management system suited for a particularnetworking technology (e.g. optical networks, ATM networks, LANS, typesof computer systems, types of software applications, etc) manages eachseparate technology domain within a multi-domain network with respect tofault, configuration, accounting, performance, and security (FCAPS)management. A higher-level system, called a comprehensive managementsystem, performs the task of managing the individual management systems.This comprehensive system collects data from the multiple lower-levelmanagement systems and, if required, sends operational instructions toeach lower-level management system.

Among other advantages, the invention enables end-to-end FCAPSmanagement, element/network/service/business management, and serviceprovisioning and monitoring from a single console over multipleinterconnected networking technologies. Important features of thecomprehensive management system of the invention include: (i)domain-specific event correlation, (ii) network, systems, andapplication management, (iii) layered Telecommunications Model Network(TIN)-style management, and (iv) FCAPS-style management.

The comprehensive network management system of the invention (i)integrates the management of networks, systems, business applications,and services (ii) integrates the areas of fault, configuration,accounting, performance, and security management, (iii) integrates theelement, network, service, and business layers of managementinformation, (iv) integrates the management of diverse networkingtechnologies, and (v) integrates the management methods of bothtelecommunications and data communications networks.

FIG. 1 is a high-level block diagram of an implementation of anembodiment of a comprehensive network management system according to thepresent invention. Further details and explanations of the individualcomponents of the invention follow this initial description. As shown inFIG. 1, in the present invention, separate technology-specificmanagement systems are utilized to manage individual technology domainsin the enterprise 110. The example embodiment of FIG. 1 has threetechnology domains. Technology domain A 102 is managed by managementsystem A 122, technology domain B 104 is managed by management system B124, and technology domain C 106 is managed by management system C 126.

Technology domains A 102, B 104, and C 106 are comprised of elementsthat are managed devices, networks, systems, and applications. A manageddevice is any device that can be modeled in a network management system.The managed devices include not only hardware devices such as personalcomputers, workstations, hubs, bridges and routers, but also softwareapplications. Domains are constructed in accordance with the particularorganizational principle by which elements are grouped in a particularnetwork. In general, network elements may be grouped in any way thatserves as an aid in understanding and managing the network. Commongrouping principles include grouping with respect to topology, devicetype, location, managerial domains, and/or the organizational structureof a network enterprise.

The management system components 122, 124, and 126 may be filled byAprisma Spectrum, Hewlett-Packard (HP) OpenView, or any other compatiblemanagement system, device or agent capable of managing the associatedtechnology domain. As discussed in more detail later, the managementsystems 122, 124, and 126 of the invention may be network managementsystems, element management systems, enterprise management systems, orany other management devices in any combination suitable for managingthe networks, devices, systems and applications in the associatedtechnology domain.

The comprehensive network management system of the invention iscomprised of conceptual layers, with each layer being successivelybroader in scope and in what it can manage. At the lowest level of theembodiment of the invention depicted in FIG. 1 is the enterprise 110 andtechnology domains 102, 104, and 106. The intermediate level of thisembodiment is an intra-domain management level, where the individualtechnology domains are managed and various intra-domain management tasksare performed. The highest level is an inter-domain management level,where the intra-domain management systems and levels are themselvesmanaged and various inter-domain management tasks are performed. Inalternate embodiments of the invention, there may be multipleintermediate layers, which may be intra-domain management levels thatmanage individual domains or other intra-domain management levels, ormay be inter-domain management levels that manage intra-domainmanagement levels or even other inter-domain management levels.

The basic structure of the present invention is therefore related towhat is sometimes called the “divide and conquer” method of networkmanagement. A network is partitioned into logical domains where eachdomain is managed more or less in isolation by low-level managementsystems. A higher-level management application then presides over thelower-level systems. This higher-level application is sometimes called amanager of managers (OM). The basic enabling technology for the presentinvention is therefore the same technology that permits the operation,administration and maintenance (OAM) of the underlying networkingtechnologies.

As shown in FIG. 1, each technology domain A 102, B 104, and C 106 hasan associated intra-domain management layer—i.e. domain A 102 isassociated with intra-domain management layer A 130, domain B 104 isassociated with intra-domain management layer B 150, and domain C 106 isassociated with intra-domain management layer C 160. The figure in thetext shows a basic two-layer management level system; however, theinvention may have any number of intermediate layers and therefore thescope of the invention includes all two and higher layer systems.

In intra-domain management layer A 130 of FIG. 1, management system A122 collects data from respective technology domain A 102 and makes itavailable to intra-domain data collection function 134. This data isthen provided to, and utilized by, inter-domain management layer 140 todetermine what intra-domain instructions should be sent fromintra-domain instruction function A 132 to management system A 122 forimplementation in respective technology domain A 102.

Similarly, in intra-domain management layers B 150 and C 160, respectivemanagement systems B 124 and C 126 collect data from respectivetechnology domains B 104 and C 106 and make it available to respectiveintra-domain data collection functions B 154 and C 164. This data isthen provided to, and utilized by, inter-domain management layer 140 todetermine what intra-domain instructions should be sent from respectiveintra-domain instruction functions B 152 and C 162 to respectivemanagement systems B 124 and C 126 for implementation in respectivetechnology domains B 104 and C 106. All of these functions are typicallyimplemented as one or more software applications, using any convenientand suitable method and/or language known in the art.

Intra-domain management layer A 130 also includes intra-domain eventcorrelation engine A 136, which receives data from management system A122 on events within domain A 102 and then maps certain of them intoalarms and possible actions to be sent back to management system A 122.There is also an intra-domain service level management (SLM) function A138 that receives service data from management system A 122 that is usedto develop service instructions to be sent back to management system A122 for management of intra-domain services.

Similarly, intra-domain management layers B 150 and C 160 also includerespective intra-domain event correlation engines B 156 and C 166 andrespective intra-domain service level management (SLM) functions B 158and C 168. The purpose and structure of these functions in the presentinvention are discussed in more detail later. These functions aretypically implemented as one or more software applications, using anyconvenient and suitable method and/or language known in the art. Thereare several commercially available systems having these functionality,including Aprisma Management Technologies' Spectrum, HP's Openview,Riversoft's, OpenRiver, Tivoli's TME, Computer Associates UniCenter,so-called “home-grown” systems, and others.

Inter-domain management layer 140 is comprised of inter-domain datacorrelation function 142, inter-domain event correlation function 146,inter-domain service level management function 144 and business processmanagement function 148. Inter-domain data correlation function 142receives the data collected by management systems A 122, B 124, and C126 from respective intra-domain data collection functions A 134, B 154,and C 164 and sends instructions to intra-domain instruction functions A132, B 152, and C 162. The inter-domain data correlation function 162 istypically implemented as a software application, using any convenientand suitable method and/or language known in the art.

Inter-domain event correlation function 146 receives inter-domain eventdata from inter-domain data correlation function 142 and uses it to mapcertain of the events into alarms and actions that are sent back tointer-domain data correlation function 142. Inter-domain service levelmanagement function 144 receives service data from inter-domain datacorrelation function 142 and uses it to manage inter-domain services.Business process management function 148 receives service managementdata from inter-domain service level management function 144 and uses itto determine whether business objectives and policies are being met, aswell as for strategic business planning. The purpose and operation ofthese functions in the present invention are discussed in more detaillater. Again, all of these functions are typically implemented as one ormore software applications, using any convenient and suitable methodand/or language known in the art and there are several commerciallyavailable systems.

It must be noted that the specific devices and systems mentioned hereinare examples only, and that alternate constructions, configurations,components, or methods of operation of the invention are to beconsidered within the scope of the invention. In particular, the networkmanagement components may include Aprisma Spectrum, HP OpenView, or anyother compatible network, enterprise or other type of management systemknown in the art. The invention may depend on a network managementsystem or on a collection of element management systems. The former isthe preferred embodiment. The communication protocols among managementsystems may use SNMP, CMIP, CORBA, TL-1 or any other compatibleprotocols. The communication protocols between management system andmanaged element may use SNMP, CMIP, CORBA, TL-1 or any other compatibleprotocols.

The purpose of the comprehensive management system of the invention isto manage all of the types of devices, media, networks, computersystems, software applications, and services that are associated with atechnology domain. Examples of the different types of networkingtechnologies that may be part of a technology domain and therefore needto be managed with the invention include, but are not limited to:virtual private networks (VPN), optical networks, Quality-of-Servicenetworks, active programmable networks, wireless networks, ATM switchednetworks, frame relay networks, cable networks, and customer premisesnetworks (LANs). Different networking technologies may be distinguishedwith respect to the properties and functionality of transmission devicesused, the type of transmission media employed, and the physics andformat of data as it travels over the media. Each presents uniquemanagement challenges that must be solved in order to achievecomprehensive management.

FIG. 2 is a table summarizing the different dimensions of integratednetwork management. Networks and their associated systems and servicesmust be viewed at multiple levels of abstraction in order to achievecomprehensive management. As shown in FIG. 2, on one level are thegeneric network components 210, such as devices, media, computers,applications, and services. At another management level are networkmanagement functions 220, such as fault, configuration, accounting,performance, and security. Still another level treats the network interms of increasing levels of abstraction 230, starting with the elementlevel, then the network level, the service level, and finally thebusiness management level. At other management levels are servicenetworks 240 and voice/data networks 250.

FIG. 3 is a block diagram illustrating the generic components of anetwork. As shown in FIG. 3, the network infrastructure is comprised ofthe transmission devices 330 that receive traffic from, and forwardtraffic to, other transmission devices. Examples of such devicesinclude, but are not limited to, routers, hubs, switches, and accessdevices for wireless networks, cable modems, satellite stations, etc.Traffic flows over the transmission media 310 and 320. Examples oftransmission media include, but are not limited to, copper wire, coaxialcable, fiber optic cable, telephone lines, and airwaves.

The generic network of FIG. 3 is also comprised of the computer systems340 that reside on a network, such as desktop computers, workstations,servers, mainframe computers, laptop computers, and even telephonydevices, the software applications 350 that run on the computer systems340, and the various services 360 that are supported by the softwareapplications 350. Examples of software applications include, but are notlimited to, document writing applications, database applications, andscientific applications that support mathematical computation andsimulations. Also included are distributed applications that spanmultiple computer systems that may even be distributed over separatenetworks. Examples of services 360 include, but are not limited to, suchthings as electronic commerce, inter-continental email, and distancelearning.

A virtual private network (VPN) is a good example of a particular typeof network that the present invention must manage. A VPN is a networkthat is constructed by using both public and private media to connecttransmission devices. For example, with reference to FIG. 3,transmission media 310 might include a public network such as theInternet, while transmission media 320 might be a business' private LAN.There are a number of systems that enable the creation of networks usingthe Internet as the medium for transporting data. These systems useencryption and other security mechanisms to ensure that only authorizedusers can access the network and that the data cannot be intercepted. Agood example is the VPN service offered by Vitts Networks via theirProtected Service Network.

One of the underlying technologies that support VPNs is called “IPtunneling.” Conceptually, the idea is a private tunnel embedded withintransmission media 310 that connects, for example, business-to-businesselectronic trading. The tunnel should be virtually impenetrable byunauthorized traffic and hackers with malicious intent. The tunnel isphysically implemented by a combination of several technologies,including encryption, packet monitoring, firewalls, and network addresstranslation (NAT). The latter technology allows businesses to hide theirprivate IP addresses behind a NAT server so that only the IP address ofthe NAT server is exposed to the public network.

VPN technology therefore raises several management challenges. One ishow issues of quality of service and service guarantees are handled.Since public media are not under the control of service providers, it isdifficult to ensure end-to-end application performance when traffictraverses public media. The current solution to this problem is toguarantee a certain quality of service only from customer premises tothe edge of the public network. Needless to say, this solution is notentirely acceptable to consumers.

In some VPN configurations, the transmission media and networks areactually owned and operated by separate service providers. Thissituation presents yet another set of management challenges. Withreference to FIG. 3, if there are a number of transmission media 310,each owned by separate service providers, then there are likely to berestrictions on what traffic is allowed to traverse the media. Thissituation is becoming common in the USA. One approach to the problem is“policy-based routing.” Simply stated, there is a policy database thatdescribes admissible flows of traffic among the edge routers of serviceprovider networks, e.g.: Port x on router A is allowed to forwardtraffic to port y on router B. As policies are modified to reflectbusiness agreements among service providers, a policy enforcerconfigures the edge routers accordingly.

Another good example of a particular type of technology that the presentinvention must manage and that presents unique management challenges isthe optical network. Optical networks (a.k.a. photonic networks, orWavelength Division Multiplexing (WDM) networks) are networks whosetransmission devices transmit data in the form of wavelength pulsesrather than electronic signals. Optical networks are deployed widely inbackbone networks in the USA and Europe for telecommunicationsapplications. The speed of data transmission over a single wavelength ismany orders of magnitude faster than electronic signals over fiber orcopper. Thus, with single wavelength optical networks, the volume oftraffic that can be carried over an optical network is limited only bythe processing power of the transmission devices, where processingincludes the translation of electronic signals into pulses andvice-versa.

The next evolution in optical networking is dense wavelength divisionmultiplexing (DWDM). The physics of light is such that forty or morewavelengths may be utilized in a single fiber and the transmissiondevices may still distinguish among them. An increase in availablebandwidth by at least forty orders of magnitude is an obvious result.The general consensus is that DWDM will be the technology of choice fornetworking during the 2000s, through which virtually unlimitedbandwidth, at least at the backbone level, will be available. However,the actual volume of traffic that can be carried over an optical networkis still going to be limited by the processing power of transmissiondevices.

Thus, in DWDM optical networks, the first challenge is to manage the newtransmission devices in the classic style of element management. Forexample, the management system must be able to monitor the performanceof each wavelength. It must assist operators in troubleshooting thenetwork by isolating questionable wavelengths and the possible locationsof degradation. A second challenge is to provide inter-operability ofWDM management agents with other network management systems.

A further management challenge presented by DWDM networks is thechallenge of service provisioning. If a service provider wishes to offeroptical bandwidth capacity to consumers, an apparatus is required toallocate, maintain, and de-allocate optical channels over the network. Asingle channel might be adequate to accommodate several small customers,while a large customer might require two or more channels. However, inorder to allocate bandwidth intelligently, the service provider willneed to know the amount of used and unused capacity per channel. Thus, amanagement system that can monitor the throughput over a DWDM opticalnetwork and infer reasonable measures of used/unused channel capacity isan important requirement.

The present invention also must manage quality of service (QoS)-basednetworks. A QoS-Based network is typically a traditional-type networkthat additionally accommodates multiple qualities of service. Theclassic example is a multi-media network that carries traffic fordiverse kinds of applications, where some traffic can withstand latencybut other traffic cannot. One example is a QoS-based network currentlyunder development at Cisco Systems, called a Multiprotocol LabelSwitching (MPLS) network. MPLS and many other QoS-based networks arebased on a resource reservation protocol.

MPLS networks are networks whose transmission devices make decisionsabout forwarding traffic based on the following constraints: (i)topology, (ii) bandwidth requirements, (iii) media requirements, and(iv) packet labeling. MPLS-based networks center around the idea ofconstraint-based routing, in which the path for a traffic flow is theshortest path that meets a set of known constraints. When packets enteran MPLS-based network, labeling edge routers (LERs) stamp them with alabel. The label contains information on the packet source, destination,bandwidth, delay, socket information, and priority. Once the LERclassifies and stamps the packet, it is assigned to a labeled switchpath (LSP). As the traffic moves over the assigned LSP, routers placeoutgoing labels on the packets, again with respect to known constraints.

Some arguments for MPLS-based networks are the following:

-   -   Near-optimal use of backbone bandwidth. Specifically, the best        route between a source and destination is determined taking into        account the known constraints.    -   Reduction in operating costs. With MPLS traffic engineering, an        operator does not have to manually configure the network devices        to set up explicit routes. The decision-making is automated in        the transmission devices.    -   Dynamic adaptation and graceful recovery. MPLS-based networks        should recover from link or node failures that change the        topology of the backbone by adapting to new sets of constraints.    -   Regulation of quality of service. From a QoS standpoint, service        providers should be able to manage different kinds of data        streams based on service priority. For instance, customers who        subscribe to a premium service plan should see minimal latency        and packet loss, while other customers should expect periodic        delays in data transmission.

A challenge for managing MPLS-based networks is to verify service levelsagreements (SLAs) made with consumers, where consumers have the optionof various service levels. This means that measurable parameters must befound to include in the agreement. Transactional response time is apopular parameter to include in an SLA. However, the guarantee istypically a blanket value, e.g. “a round trip delay of packets sent fromthe customer site to the edge of the Internet of 50 milliseconds orless.” Response time management will be harder with MPLS-based networks,and with QoS-based networks in general. Since there will be multiplegrades of services offered to consumers, and assuming that transactionalresponse time continues to be used as a performance measure in SLAs,then there will essentially be multiple response time guarantees. Thisclearly will add further complexity to the service providers' managementsystems.

Further management challenges are presented by the nascent technologyknown as active networks. Active networks, unlike traditional networks,are not passive carriers of bits but instead provide the capability forthe user to inject customized programs into the networks. The networknodes interpret these programs and perform the desired operation on thedata flowing through the network. Management challenges presented byactive networks include the need for a closer monitoring of the packetsand data elements that traverse the network, since networks will now becontrolled by the traffic flowing through them rather than the other wayaround. Configuration management, the management area involving settingup transmission devices, will also need to be treated in a new manner.In particular, note that it is also possible for only part of anend-to-end network to be occupied by an active network, and thuscomprehensive management will be required.

The previous discussion has focused on some of the different types ofnetworking technologies that can be managed by the comprehensive networkmanagement system of the invention. It is clear that there are alsoother types of elements between the networking components and theend-user that must be managed including, for example, computers,applications, and video, voice, application and data services. Thus, themanagement of network services extends beyond management of just thenetwork.

The present invention makes use of integration of element and networkmanagement. FIG. 4 illustrates two different conceptual models for thistask. The dotted lines in FIG. 4 indicate “managed scope” and thehorizontal lines indicate the divisions between the network and servicemanagement level 420, the element management level 430, and the elementlevel 440. Block 410 illustrates an element-centric management system.In the element-centric approach, there is a collection of elementmanagement systems 450 for managing elements 470. Each elementmanagement system 450 passes management information to a higher-levelnetwork management system 460. It can be seen that method 410 includesan intermediary set of element management systems 450 (indicated byblack nodes) between the network management system 460 and the “bare”network elements 470. Thus, the network management system 460 is onceremoved from the bare elements 470. Block 480 illustrates anetwork-centric management system, in which the network managementsystem 460 communicates directly with the elements 470.

Both approaches are seen in the industry. The latter approach, forexample, is taken by Aprisma's Spectrum. There are trade-offs betweenthe two approaches. Spectrum is popular in the industry in part becauseit provides multi-vendor management from a single management station.This means, however, that Spectrum engineers have to build managementmodules for new element types as they enter the market, which in turnmeans that they have to understand the differences between old and newnetwork technologies, the information models of each technology, and thespecific management methods required by each technology. This is, ofcourse, feasible, but it is very labor-intensive.

The element-centric approach requires roughly an equal amount of work,but has as a clear disadvantage the common problem of the proliferationof point management solutions, each requiring deployment, configuration,and operational learning curves. A further disadvantage is the lack of aconsistent operational interface. What often happens, therefore, is thatnew technologies are developed in research labs in accordance with theelement-centric philosophy, in order to initially develop appropriatemanagement techniques. Once the technology settles, vendors such asAprisma incorporate the management methods into an existing commercialnetwork management system. It is expected that this approach willfrequently be utilized in the addition of new managed elements andsystems to the lower-level management systems of the invention. Anadvantage of the present invention is that these additions will behidden from the higher, inter-domain levels, vastly reducing the needfor such things as operational learning curves.

In the industry, the word “enterprise management” has come to connotethe management of applications, systems, and networks. In this respect,an enterprise management system is already a multi-domain managementsystem. FIG. 5 is a block diagram illustrating the conceptualarchitecture of an enterprise management system that may be employed forcross-domain management in an embodiment of the invention.

In FIG. 5, network management system or systems 510, systems manager ormanagers 520, and application manager or managers 530 are themselvesmanaged by enterprise management system 500. The various underlyingmanagement systems 510, 520 and 530 may be any of the many suchmanagement systems known in the art that are capable of being managed byan enterprise management system. Enterprise management system 500 may bethe Aprisma Spectrum Enterprise Manager or any other management systemknown in the art that is capable of managing the various underlyingmanagement systems 510, 520, and 530.

Often, management systems 122, 124, and 126 of FIG. 1 will be enterprisemanagement systems. However, not all management systems will have tomonitor and control computer systems and applications in addition to thenetwork. For example, the management of an optical network does notinclude the management of end user systems and applications, althoughthe health of an optical network will affect the health of end userapplications. For this reason, management systems 122, 124, and 126 inFIG. 5 may be simple network, application, or systems managers oragents.

While enterprise management and the comprehensive management of theinvention share certain elements, there are a number of aspects ofcomprehensive management that enterprise management cannot provide. Byits very definition, enterprise management is not truly comprehensive innature, being specifically established to provide network, traffic,computer system and application management solely for a singleenterprise (i.e. a single business entity). The comprehensive managementof the invention is, in many ways, the sum of enterprise management,plus service provider network management for as many service providersas are part of the system being managed. Further, enterprise managementtypically does not manage according to the levels in the TMN hierarchy,discussed later with reference to FIG. 9, does not provide Service LevelManagement, discussed later with reference to FIG. 10, or deal with theinterface between the two. In addition, the comprehensive management ofthe invention includes the management of multiple networkingtechnologies, at the core network, edge network, and customer premisesand, in particular, allows the TMN model and service level management tobe applied to all these domains. Finally, the comprehensive managementof the present invention provides both business level management and agenerally higher level of management abstraction, neither of which isavailable with enterprise management.

FIG. 6 is used to illustrate the manner in which the invention may beused to manage an example network—a multi-provider VPN. FIG. 1illustrated how the management systems of the present invention eachmanage individual networking technology domains. The example embodimentin FIG. 6 shows three such domains: a customer premises network 610, anATM network 620, and an optical backbone 614. In this embodiment, theindividual elements in each of domains 610, 612, and 614 are managed byappropriate device managers 620. The device managers 620 within eachdomain are themselves managed by a domain-specific network managementsystem 630.

In this example, each network is provided and operated by a third partyutilizing its own management platforms and management processes. Ifthere is a VPN that spans across all of those networks, then clearly themanagement of the VPN depends upon management information collected bythe respective domain network management systems 620. Thus, FIG. 1 showsintra-domain data from domains A 102, B 104, and C 106 being passed toan inter-domain data correlation function 142. The inter-domain datacorrelation function 142 processes intra-domain data and returns databack to domains A 102, B 104, and/or C 106 in the form of operationalinstructions. Such operational instructions may have to do with faults,configurations, or service provisioning

In fact, large businesses often have to construct VPNs that span acrossmultiple heterogeneous networks, where some of the networks areprivately owned. This “separation challenge” is illustrated in FIG. 7.FIG. 7 is a conceptual depiction of a such a network, having manageddomains controlled by different entities. In FIG. 7, domain X 720 ismanaged by provider A 730, but a service S 710 offered by A depends upona domain Y 740 that is managed by provider B 750. As mentioned, thisseparation challenge is common in the industry. The result of such asituation, from the network operator's point of view, is managementcomplexity in terms of security management, operations management,problem management, configuration management, policy management, changemanagement. The present invention is specifically designed to reduce oreliminate these problems.

There are four logical approaches to the problem presented by theexample of FIG. 7:

-   1. A limits its service offerings to those that depend upon the    networks under its control.-   2. A doesn't offer service guarantees in cases where the service    depends upon networks not under its control.-   3. A and B enter an arrangement whereby network operators    collaborate to handle service degradations and faults.-   4. B opens its domain to A's management system, or vice versa.

As can be seen, approaches 1 and 2 sidestep the separation problemaltogether, while approaches 3 and 4 tackle it head on. In particular,approach 4 returns directly to the need for the integrated managementprovided by the comprehensive network management system of theinvention.

Another common manifestation of the separation problem is seen evenwithin businesses that control their own local services, where, forexample, A is a staff dedicated to network management (domain X) and Bis a staff dedicated to systems and applications management (domain Y).Often it seems that these people rarely talk to each other, and whenthey do, it takes the form of finger-pointing. Clearly, an integratedmanagement system would also help to alleviate this internal separationproblem.

The preferred embodiment of the invention employs domain-specific eventcorrelation. Event correlation entails observing cause-and-effectrelations between certain events, inferring an alarm from a set ofrelated events, and/or identifying the “culprit” event in a“misbehaving” enterprise. In practice, a particular network managementsystem will collect numerous events and statistics as it monitors theelements in its respective domain. The task of event correlation is tomap certain collections of events scattered in space and time intoalarms and possible actions. There are several paradigms in the industryfor event correlation, including rule-based reasoning, model-basedreasoning, state transition graphs, codebooks, and case-based reasoning.Additional paradigms are also currently being investigated in researchlaboratories, e.g. fuzzy logic and neural networks.

FIG. 8 depicts intra-domain event correlation as utilized by the presentinvention. As shown in FIG. 8, domain 810 is subject to event monitoring820. When events occur, they are processed by the event correlationengine 830 and mapped into alarms and actions 840. Any of the paradigmsfor event correlation mentioned previously would be suitable. Manycommercial management systems, including Spectrum, now either have eventcorrelation engines or are integrable with them.

Regardless of the particular paradigm used, domain-specific eventcorrelation is another example of the “divide and conquer” approach tonetwork management that is employed by the present invention. Ingeneral, single event correlation engine for a large heterogeneousnetworking system will not scale. Thus, it is advisable to employseparate correlation engines for each individual domain, where theoutput of each engine is passed to a higher-level correlation engine.The inter-domain data correlation function 146 of FIG. 1 is such ahigher-level correlation engine. In this capacity, its domain, i.e. itsinput, is the space of intra-domain alarms.

The invention therefore requires correlation engines for bothlower-level intra-domain management systems and for higher-levelinter-domain management systems. The idea is similar to the concept of amanager of managers (MOM). There are in fact several commercial productsavailable that act as MOMs. Their sole function is to receive input datafrom lower-level network or element management systems, process thedata, and output data in the form of reports and recommended actions.

The additional consideration of systems and application management tiesin with the need for domain-specific event correlation. A commonquestion regarding an end user's complaint is “Is it a network, systems,or application problem?” A response time management (RTM) system, forexample, can raise a problem regarding sluggishness in applicationtransactions, but further work needs to be done in order to determinewhether the cause of the problem has to do with the application, thecomputer system on which the application resides, or the network. Anevent correlation system that covers systems and application eventshelps in isolating the root cause of the problem.

An important concept in network management is the five-layerTelecommunications Management Network (TMN) model shown in FIG. 9. TheTMN model is partitioned into five layers: the element layer 910, theelement management layer 920, the network or enterprise management layer930, the service management layer 940, and the business management layer950. Each layer, going from bottom to top, represents a transformationfrom technical detail towards more business-oriented information.

The business layer 950 is concerned with the overall management of thebusiness. As such, it covers aspects relating to business processes andstrategic business planning. Further, it seeks to capture informationthat may be used to determine whether business objectives and policiesare being met. The service management layer 940 is concerned with themanagement of services provided by a service provider to a customer orto another service provider. Examples of such services include billing,order processing, and trouble ticket handling. The enterprise/networkmanagement layer 930 is concerned with a network with multiple elements.As such, it supports network monitoring and remote configuration. Inaddition, this layer supports issues such as bandwidth control,performance, quality of service, end-to-end flow control and networkcongestion control. The element management layer 920 is concerned withthe management of individual network elements including, for example,switches, routers, bridges, and transmission facilities. The elementlayer 910 refers to the bare elements that are to be managed.

The TMN idea has influenced those businesses that own their own networksas well as businesses that outsource pieces of the network operation toservice providers. For the most part, commercial networks are manageableup to, and including, the network layer. The ideas of “services” and“service level agreements” are now on the minds of business executivesand service providers.

A service may be viewed from a user's point of view, from a business'point of view, or from the network's point of view. The service providedby an optical network, for example, is the allocation of bandwidth to acustomer. This service from a business' point of view may be decomposedinto the service provided by the optical network plus the servicesprovided by its own local network, systems, and applications. This istherefore yet another example of the divide and conquer technique,whereby a higher-level service is comprised of several lower-levelservices. Thus, with reference to FIG. 1, end-to-end services aremanaged at inter-domain level 140, and local services are managed at theintra-domain levels 130, 150 and 160.

FIG. 10 is a conceptual depiction of how service level management istherefore utilized in conjunction with enterprise management in anembodiment of the invention. In FIG. 10, network management system orsystems 1040, systems manager or managers 1030, and application manageror managers 1020 are themselves managed by enterprise management system1010. In turn, enterprise manager 1010 is subject to service levelmanagement 1050. As previously discussed, service level management 1050is concerned with the management of services provided by a serviceprovider to a customer or another service provider. As in FIG. 5, thenetwork management layer may possibly include the management of computersystems and software applications that reside on the network, and theterm “element” is used to include individual systems and applications inaddition to transmission devices.

As mentioned previously, the invention provides classical FCAPSmanagement (fault, configuration, accounting, performance, and securitymanagement). Fault management includes trouble management, which managescorrective actions for service, fault recovery, and proactivemaintenance and provides capabilities for self-healing. Troublemanagement correlates alarms to services and resources, initiates tests,performs diagnostics to isolate faults to a replaceable component,triggers service restoral, and performs activities necessary to repairthe diagnosed fault. Proactive maintenance responds to near-faultconditions that degrade system reliability and may eventually result inan impact on services. It performs routine maintenance activities on ascheduled basis and initiates tests to detect or correct problems beforeservice troubles are reported.

Configuration management includes timely deployment of resources tosatisfy the expected service demands, and the assignment of services andfeatures to end-users. It identifies, exercises control over, collectsdata from, and provides data to the network for the purpose of preparingfor, initializing, starting, and providing for the operation andtermination of services. It deals with logical, service, or customnetworks such as the toll network, local public switched telephonenetwork, and private networks. Accounting management processes andmanipulates service and resource utilization records and generatescustomer billing reports for services rendered. It establishes chargesand identifies costs for the use of services and resources in thenetwork.

Performance management addresses processes that ensure the mostefficient utilization of network resources and their ability to meetuser service-level objectives. It evaluates and reports on the behaviorof network resources and ensures the peak performance and delivery ofeach voice, data, or video service. Security management controls accessto, and protects, both the network and network management systemsagainst intentional or accidental abuse, unauthorized access, andcommunication loss. Flexibility methods are built into securitymechanisms in order to accommodate ranges and inquiry privileges thatresult from the variety of access modes utilized by operations systems,service provider groups, and customers.

Multi-wave optical networks can be used as an example to illustrate howthe TMN model and FCAPS management are applied to a new technology inorder that it can be managed with the comprehensive network managementsystem of the invention. As previously mentioned, multi-wave opticalnetworks promise to change the face of communications by enablingadvanced applications in federal, scientific, and commercial sectors.The first problem in managing multi-wave optical networks, however, isto develop what is sometimes called an “information model” for the newnetworking technology, i.e. a model that depicts the physics of opticalnetworks in terms of management concepts. For example, the informationmodel of multi-wave optical networks includes models of opticalcomponents (optical-to-electronic terminating equipment, multiplexingequipment, optical amplifiers, etc.) and models of wavelengths (e.g.section trails, multiplex trails, and channel trails). Typically, theinformation model is used also as a base to develop FCAPS-style andTMN-style management methods for the technology.

Consider what a commercial network management vendor has to worry aboutin this kind of situation: The vendor is not in the business ofdeveloping optical networks. It is in the business of managing them.However, in order to understand how to manage them, the vendor'sscientists and architects have to keep close watch on the development ofthe technology, its special management methods, and its commercialviability.

Aprisma Management Technologies is an example of such a vendor.Aprisma's Spectrum is commercially popular; it is good at managingexisting enterprise networks, service provider networks, ATM and framerelay networks, cable networks, and others. It is also good atmulti-vendor device management and event correlation over single- andmulti-domain networks. Aprisma's stated goal is to provide acomprehensive management solution and, in that regard, it competes withvendors such as HP, Tivoli Computer Associates, Objective Systems, and anumber of start-up companies in the network management space.

The Spectrum system is based on the object-oriented informationparadigm, whereby network components are conceived as objects thatrepresent their real-world counterparts. An object-oriented system helpsto alleviate the problem of introducing models of multi-vendor elementsinto an existing system. Further; it expedites the generation ofmanagement methods for domains other than networks and network elements.Systems, applications, and service management products are incorporatedinto Spectrum by third-party vendors.

The object-oriented paradigm is more or less a de facto paradigm fordeveloping information models for new networking technologies, includingmulti-wave optical networks. Since Spectrum's information model is basedon the object-oriented paradigm, there is a fortunate commensurabilitybetween it and the information models of new networking technologies. Itis hard, however, to predict how the information models developed bydifferent networking vendors or vendor consortia will stabilize into astandard, even though they are based on the object-oriented paradigm.

A need in the industry as a whole is to develop a common language forspecifying network technologies and the management of them. This, infact, is the main goal of standards bodies. A good start in thatdirection is the ITU-T Recommendation G.805—Generic Network InformationModel (1995). Many of the management concepts for optical networks, forexample, are derived from that document. It is therefore advisable thatframeworks for network management systems migrate towards an alignmentwith such information models. In the preferred embodiment of theinvention, this approach is followed.

As previously seen, today's business and service networks are complex.The current state of any particular network has more than likely evolvedin a piecemeal fashion, and thus it will include heterogeneous kinds ofnetwork technologies, equipment from multiple vendors, and various kindsof management methods. To make matters worse, management methods varybetween countries and even between districts within countries. In manycases, the result is either piecemeal management, in which narrowlyfocused management solutions co-exist but do not cooperate, or nomanagement at all. The solution is integrated management, in which thesemanagement techniques cooperate in a standardized management framework.Thus, the ultimate goal of international standards bodies is to providea uniform framework and methodology in order to correct the currentsituation. The problem, however, is that the standardization process isoften slow and sometimes doesn't mature into a globally acceptedstandard.

The goal of a generic framework by which to manage diverse networkingtechnologies is certainly a good idea. However, no matter how much avendor wants to develop a comprehensive, single-console managementsystem, there will still be times when an integration with anothervendor's management system makes good sense. A good example is theintegration of an existing management system with a legacy managementsystem.

Further, there is a valid argument that no one vendor can provide allthe solutions. As a practical matter, vendors tend to be more or lessspecialists in one domain or another. For example, some are good atbuilding network management systems, some are good at building networksimulation systems, some are good at building trouble ticket and helpdesk systems, etc. Thus, a direction for future work is to cataloguevarious kinds of integration patterns and mechanisms by which toimplement them.

A high-level operational flowchart of comprehensive network managementaccording to one aspect of the invention is shown in FIG. 11. In FIG.11, the functional steps starting at box 1110 are carried outsimultaneously at all the levels of abstraction of the invention. Inother words, the same steps are carried out from the businessperspective 1112, the service perspective 1114, the inter-domainperspective 1116, and the intra-domain perspective 1118. All that variesis the level of abstraction upon which the steps operate and thecorresponding level of abstraction of the input data and outputinstructions.

As shown in FIG. 11, data is collected 1130 at a particular level ofabstraction by use of an appropriate data collection function. The datais then interpreted 1140 from the appropriate level of abstractionperspective. The manner of interpreting data may be carried out by anyof the many means known in the art, including, but not limited to,look-up tables, expert systems, machine learning systems, etc. If thedata interpretation 1140 determines that instructions are required forsubmanagers at a lower level of abstraction 1150, an instructionfunction at the appropriate level of abstraction sends the requiredinstructions 1160 to the appropriate submanagers.

For example, with reference also to FIG. 1, data from domains A 102, B104, and C 106 is collected 1130 by intra-domain data collectionfunctions A 134, B 154 and C 164 at the intra-domain level 1118 (130,150, 160) and provided to the inter-domain level 1116 (140) where it isprocessed by the inter-domain data correlation function 142.Inter-domain data correlation function 142 may also provide this data tointer-domain event correlation function 146. If data correlationfunction 142 determines, either from its own analysis or based onfeedback from inter-domain event correlation function 146, thatinstructions to management systems A 122, B 124 and/or C 126 arerequired 1150, then inter-domain data correlation function 142 providesinstructions to one or more of intra-domain instructions functions A132, B 152, and C 162 at the intra-domain level 1118 (130, 150, 160).Intra-domain instructions functions A 132, B 152, and C 162 then provideappropriate instructions to respective management systems A 122, B 124and C 126 at the intra-domain level 1118 (130, 150, 160). From thisexample, it is to be understood that the actions of the invention at theother levels of abstraction would have a similar character, according tothe principles around which that level of abstraction is organized.

The following steps are development steps by which the current inventionmay be constructed for each individual technology domain.

1. Element development

2. Element-style management

3. Fault and Configuration Management in Element-style Management

4. Network-style management

5. Intra-domain event correlation

6. Intra-domain service level management

7. Inter-domain network management

8. Inter-domain event correlation

9. Inter-domain service level management

10. Inter-domain business process management

It is to be understood that these steps apply to the implementation ofmanagement of a single domain, and that similar development steps wouldtherefore need to be applied to each technology domain in order to fullyrealize the comprehensive network management system of the invention.

What has been described herein is merely illustrative of the applicationof the principles of the present invention. Other arrangements, methods,modifications and substitutions by one of ordinary skill in the art arealso considered to be within the scope of the present invention, whichis not to be limited except by the claims that follow.

1. A method for comprehensively managing a communications environment,wherein the communications environment comprises a plurality of networkdomains, each network domain comprising a separately managedcommunications network having intra-domain management components, theintra-domain management components comprising: an intra-domain datamanagement component that manages the network domain; an intra-domainevent correlation component that receives events from the intra-domaindata management component, maps the events into one or more of alarms oractions, and transmits the alarms or actions to the intra-domain datamanagement component; and an intra-domain service level managementcomponent that receives service data relating to levels of serviceprovided by the network domain from the intra-domain data managementcomponent, formulates intra-domain service instructions using theservice data, and transmits the intra-domain service instructions to theintra-domain data management component, the method comprising:receiving, at an inter-domain data collection module, domain-specificdata from the intra-domain management components of two or more networkdomains of the plurality of network domains, wherein the domain-specificdata includes service data and event data, wherein event data includesdata relating to one or more of events or alarms mapped from events;receiving, at an inter-domain event correlation module, event datarelating to the at least two network domains from the inter-domain datacollection module; determining, at the inter-domain event correlationmodule, whether to generate one or more inter-domain events based on thereceived event data; receiving, at an inter-domain service levelmanagement module, service data relating to the at least two networkdomains from the inter-domain data collection module; comparing, at theinter-domain service level management module, the received service datawith one or more predefined service levels; generating, at theinter-domain service level management module, one or more inter-domainservice management actions based on the comparison; receiving, at abusiness process management module, one or more of the service datarelating to the at least two network domains or the generated one ormore inter-domain service management actions from the inter-domainservice level management module; and determining, at the businessprocess management module, whether one or more predefined businessobjectives are met using one or more of the service data or theinter-domain service management actions.
 2. The method of claim 1,wherein generating one or more inter-domain service management actionsfurther comprises: generating, at the inter-domain service levelmanagement module service instructions based on the one or moreinter-domain service management actions; receiving, at the inter-domaindata collection module, the service instructions from the inter-domainservice level management module; and transmitting, from the inter-domaindata collection module, the service instructions to one or more of theintra-domain data management components of the at least two networkdomains.
 3. The method of claim 1, wherein determining whether togenerate one or more inter-domain events further comprises: correlating,at the inter-domain event correlation module, the received event datainto one or more inter-domain events; determining, at the inter-domainevent correlation module, whether to generate one or more inter-domainalarms based at least in part on the one or more inter-domain events;generating, at the inter-domain event correlation module, one or moreinter-domain actions when one or more inter-domain alarms are generated;receiving, at the inter-domain data collection module, the one or moregenerated inter-domain actions; and transmitting, from the inter-domaindata collection module, the one or more generated inter-domain actionsto one or more of the intra-domain data management components of the atleast two network domains.
 4. A computer readable storage medium storingcomputer executable instructions for comprehensively managing acommunications environment, wherein the communications environmentcomprises a plurality of network domains, each network domain comprisinga separately managed communications network having intra-domainmanagement components, the intra-domain management componentscomprising: an intra-domain data management component that manages thenetwork domain; an intra-domain event correlation component thatreceives events from the intra-domain data management component, mapsthe events into one or more of alarms or actions, and transmits thealarms or actions to the intra-domain data management component; and anintra-domain service level management component that receives servicedata relating to levels of service provided by the network domain fromthe intra-domain data management component, formulates intra-domainservice instructions using the service data, and transmits theintra-domain service instructions to the intra-domain data managementcomponent, the instructions operable when executed to: receive, at aninter-domain data collection module, domain-specific data from theintra-domain management components of two or more network domains of theplurality of network domains, wherein the domain-specific data includesservice data and event data, wherein event data includes data relatingto one or more of events or alarms mapped from events; receive, at aninter-domain event correlation module, event data relating to the atleast two network domains from the inter-domain data collection module;determine, at the inter-domain event correlation module, whether togenerate one or more inter-domain events based on the received eventdata; receive, at an inter-domain service level management module,service data relating to the at least two network domains from theinter-domain data collection module; compare, at the inter-domainservice level management module, the received service data with one ormore predefined service levels; generate, at the inter-domain servicelevel management module, one or more inter-domain service managementactions based on the comparison; receive, at a business processmanagement module, one or more of the service data relating to the atleast two network domains or the generated one or more inter-domainservice management actions from the inter-domain service levelmanagement module; and determine, at the business process managementmodule, whether one or more predefined business objectives are met usingone or more of the service data or the inter-domain service managementactions.
 5. The computer readable storage medium of claim 4, wherein theinstructions when executed operable to generate one or more inter-domainservice management actions are when executed further operable to:generate, at the inter-domain service level management module serviceinstructions based on the one or more inter-domain service managementactions; receive, at the inter-domain data collection module, theservice instructions from the inter-domain service level managementmodule; and transmit, from the inter-domain data collection module, theservice instructions to one or more of the intra-domain data managementcomponents of the at least two network domains.
 6. The computer readablestorage medium of claim 4, wherein the instructions when executedoperable to determine whether to generate one or more inter-domainevents are when executed further operable to: correlate, at theinter-domain event correlation module, the received event data into oneor more inter-domain events; determine, at the inter-domain eventcorrelation module, whether to generate one or more inter-domain alarmsbased at least in part on the one or more inter-domain events; generate,at the inter-domain event correlation module, one or more inter-domainactions when one or more inter-domain alarms are generated; receive, atthe inter-domain data collection module, the one or more generatedinter-domain actions; and transmit, from the inter-domain datacollection module, the one or more generated inter-domain actions to oneor more of the intra-domain data management components of the at leasttwo network domains.
 7. A system for comprehensively managing acommunications environment, wherein the communications environmentcomprises a plurality of network domains, each network domain comprisinga separately managed communications network having intra-domainmanagement components, the intra-domain management componentscomprising: an intra-domain data management component that manages thenetwork domain; an intra-domain event correlation component thatreceives events from the intra-domain data management component, mapsthe events into one or more of alarms or actions, and transmits thealarms or actions to the intra-domain data management component; and anintra-domain service level management component that receives servicedata relating to levels of service provided by the network domain fromthe intra-domain data management component, formulates intra-domainservice instructions using the service data, and transmits theintra-domain service instructions to the intra-domain data managementcomponent, the system comprising: one or more processors configured to:receive, at an inter-domain data collection module, domain-specific datafrom the intra-domain management components of two or more networkdomains of the plurality of network domains, wherein the domain-specificdata includes service data and event data, wherein event data includesdata relating to one or more of events or alarms mapped from events;receive, at an inter-domain event correlation module, event datarelating to the at least two network domains from the inter-domain datacollection module; determining, at the inter-domain event correlationmodule, whether to generate one or more inter-domain events based on thereceived event data receive, at an inter-domain service level managementmodule, service data relating to the at least two network domains fromthe inter-domain data collection module; compare, at the inter-domainservice level management module, the received service data with one ormore predefined service levels; generate, at the inter-domain servicelevel management module, one or more inter-domain service managementactions based on the comparison; receive, at a business processmanagement module, one or more of the service data relating to the atleast two network domains or the generated one or more inter-domainservice management actions from the inter-domain service levelmanagement module; and determine, at the business process managementmodule, whether one or more predefined business objectives are met usingone or more of the service data or the inter-domain service managementaction.
 8. The system of claim 7, wherein the one or more processorsconfigured to generate one or more inter-domain service managementactions are further configured to: generate, at the inter-domain servicelevel management module service instructions based on the one or moreinter-domain service management actions; receive, at the inter-domaindata collection module, the service instructions from the inter-domainservice level management module; and transmit, from the inter-domaindata collection module, the service instructions to one or more of theintra-domain data management components of the at least two networkdomains.
 9. The system of claim 7, wherein the one or more processorsconfigured to determine whether to generate one or more inter-domainevents are further configured to: correlate, at the inter-domain eventcorrelation module, the received event data into one or moreinter-domain events; determine, at the inter-domain event correlationmodule, whether to generate one or more inter-domain alarms based atleast in part on the one or more inter-domain events; generate, at theinter-domain event correlation module, one or more inter-domain actionswhen one or more inter-domain alarms are generated; receive, at theinter-domain data collection module, the one or more generatedinter-domain actions; and transmit, from the inter-domain datacollection module, the one or more generated inter-domain actions to oneor more of the intra-domain data management components of the at leasttwo network domains.
 10. A method for managing a communications networkcomprising a first domain managed at a first management layer and asecond domain managed at a second management layer, the methodcomprising: receiving first service management information from thefirst management layer and second service management information fromthe second management layer, wherein the first service managementinformation was correlated, at the first management layer, from aplurality of first service information, the first service managementinformation comprising information related to services being provided byone or more first service providers at the first domain, wherein thesecond service management information was correlated, at the secondmanagement layer, from a plurality of second service information, thesecond service management information comprising information related toservices being provided by one or more second service providers at thesecond domain; correlating the first service management information withthe second service management information; and generating inter-domainservice management information based on the correlated first servicemanagement information and second service management information,wherein the inter-domain service management information comprisesinformation related to services being provided on the communicationsnetwork.
 11. The method of claim 10, further comprising: generatingfirst service instructions based on the generated inter-domain servicemanagement information.
 12. A computer readable storage medium storingcomputer executable instructions for managing a communications networkcomprising a first domain managed at a first management layer and asecond domain managed at a second management layer, the instructionsoperable when executed to: receive first service management informationfrom the first management layer and second service managementinformation from the second management layer, wherein the first servicemanagement information was correlated, at the first management layer,from a plurality of first service information, the first servicemanagement information comprising information related to services beingprovided by one or more first service providers at the first domain,wherein the second service management information was correlated, at thesecond management layer, from a plurality of second service information,the second service management information comprising information relatedto services being provided by one or more second service providers atthe second domain; correlate the first service management informationwith the second service management information; and generateinter-domain service management information based on the correlatedfirst service management information and second service managementinformation, wherein the inter-domain service management informationcomprises information related to services being provided on thecommunications network.
 13. The computer readable medium of claim 10,the instructions when executed further operable to: generate firstservice instructions based on the generated inter-domain servicemanagement information.
 14. A system for managing a communicationsnetwork, the communications network comprising a first domain managed ata first management layer and a second domain managed at a secondmanagement layer, the system comprising: one or more processorsconfigured to: receive first service management information from thefirst management layer and second service management information fromthe second management layer, wherein the first service managementinformation was correlated, at the first management layer, from aplurality of first service information, the first service managementinformation comprising information related to services being provided byone or more first service providers at the first domain, wherein thesecond service management information was correlated, at the secondmanagement layer, from a plurality of second service information, thesecond service management information comprising information related toservices being provided by one or more second service providers at thesecond domain; correlate the first service management information withthe second service management information; and generate inter-domainservice management information based on the correlated first servicemanagement information and second service management information,wherein the inter-domain service management information comprisesinformation related to services being provided on the communicationsnetwork.
 15. The system of claim 10, the one or more processors furtherconfigured to: generate first service instructions based on thegenerated inter-domain service management information.
 16. A method forcomprehensively managing a communications network comprising a firstnetwork and a second network, the method comprising: receiving firstnetwork management information collected at a first domain, wherein thefirst domain is connected to the first network, the first networkemploying a first type of network technology; receiving second networkmanagement information collected at a second domain, wherein the seconddomain is connected to the second network, the second network employinga second type of network technology, wherein the first type of networktechnology is different from the second type of network technology;generating a first information model that describes management of thefirst network and generating a second information model that describesmanagement of the second network; correlating the first networkmanagement information with the second network management informationusing the first information model and the second information model;generating inter-domain results based on the correlation; anddetermining one or more first operational instructions according to thefirst type of network technology employed by the first network, whereinthe one or more first operational instructions are based on thegenerated inter-domain results and are implemented at the first domain.17. The method of claim 16, wherein the communications network is avirtual private network (VPN) that traverses the first network and thesecond network.
 18. The method of claim 16, wherein the firstinformation model is based on a common language for specifying networktechnologies.
 19. A method for comprehensively managing a communicationsnetwork comprising a first network and a second network, the methodcomprising: receiving first network management information collected ata first domain, wherein the first domain is connected to the firstnetwork, the first network employing a first type of network technology;receiving second network management information collected at a seconddomain, wherein the second domain is connected to the second network,the second network employing a second type of network technology,wherein the first type of network technology is different from thesecond type of network technology; generating a first information modelthat describes management of the first network and generating a secondinformation model that describes management of the second network;correlating the first network management information with the secondnetwork management information using the first information model and thesecond information model; and generating inter-domain results based onthe correlation; wherein the first type of network technology comprisesan optical networking technology and wherein the generated firstinformation model relates to physics of the optical networkingtechnology.
 20. The method of claim 19, wherein said generating a firstinformation model further comprises modeling one or more opticalcomponents of the first network.
 21. The method of claim 20, wherein theone more optical components of the first network comprises at least oneof the following: an optical-to-electronic terminating equipment, amultiplexing equipment, or an optical amplifier.
 22. The method of claim20, wherein said generating a first information model further comprisesgenerating one or more models of wavelengths.
 23. The method of claim22, wherein the one or more models of wavelengths comprise at least oneof the following: at least one section trail, at least one multiplextrail, or at least one channel trail.